COMMENT ⊗   VALID 00012 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	\input basic
C00004 00003	\ctrline{\bf Portable Common Lisp Research and Development}
C00009 00004	\vskip .25truein
C00020 00005	\vskip .25truein
C00024 00006	\vskip .25truein
C00030 00007	\vskip .25truein
C00035 00008	\vskip .25truein
C00040 00009	\vskip .25truein
C00043 00010	\vskip .25truein
C00047 00011	% References
C00052 00012	% Budget    
C00055 ENDMK
C⊗;
\input basic
\jpar 1000
\varunit 1truein
\parskip .15in plus 5pt \baselineskip 15pt \lineskip 1pt
\def\rm{\:a} \def\sl{\:n} \def\bf{\:q} \def\it{\:?}
\font m=cmsc10 		%  Small caps
\font <=cmb10		%  Bolder
\def\sc{\:m}		%  Small Caps  (10pt)
\output{\baselineskip 18pt\page}

\ctrline{\bf Portable Common Lisp Research and Development}
\vskip 1truein
\ctrline{\bf Proposal to}
\ctrline{\bf The Defense Advanced Research Projects Agency}
\vskip 3truein
\ctrline{\bf Principal Investigator}
\vskip 1truein
\ctrline{\bf John McCarthy}
\ctrline{\bf Professor of Computer Science}
\ctrline{\bf Stanford University}
\vfill\eject
\output{\baselineskip 18pt\page\ctrline{\curfont a\count0}\advcount0}
\def\ref:#1.#2.{[\hbox{#1 #2}]}
\def\makeref:#1.#2.#3{\par{\noindent \parshape 2 0truein 6.5truein
.5truein 6.0truein \hbox{[\hbox{#1 #2}]}\linebreak 
{#3}}\par\parshape 0\vfil\penalty 0\vfilneg}
\def\article#1{{\sl #1}}
\def\book#1{{\:< #1}}
\def\S-1{\hbox{S-1}}
\def\textindent#1{\noindent\hbox to 19pt{\hskip 0pt plus 1000pt minus 1000pt#1\ 
\!}}
\def\hang{\hangindent 19pt}

\def\numitem#1{\yskip\hang\textindent{#1}}
\def\yyskip{\penalty-100\vskip8pt plus6pt minus4pt}
\def\yskip{\penalty-50\vskip 3pt plus 3pt minus 2pt}
\ctrline{\bf Portable Common Lisp Research and Development}
\vskip .5truein
\ctrline{by}
\vskip .5truein
\ctrline{John McCarthy}
\ctrline{Professor of Computer Science}
\ctrline{Stanford University, Stanford, CA 94305}
\vskip .5truein
\ctrline{Proposed research:}
\ctrline{Advanced Research Projects Agency}
\ctrline{October 1, 1983---September 31, 1986}
\vskip 1truein

\ctrline{\bf Motivation}

Around 1976 the course of artificial intelligence research was adversely
affected by the `Lisp crisis'---address space limitations.  The major Lisp
implementations (MacLisp \ref:Moon.1974. and InterLisp
\ref:Teitelman.1978.) ran on PDP-10's; the address space limitations of the
PDP-10 had become or were to become intolerable.  Something had to change,
but the change was never seen as a potentially traumatic event---not until
the Vax 11/780 appeared.

Vax becoming the `mainframe of the future' meant that a congenial
architecture for Lisp, such as the PDP-10 had, would not be available on
popular stock hardware.  Also, Lisp implementors could see the dozens of
man-years' of effort in an assembly-language-coded runtime system wash
down the drain. Never again could such a dead-end effort be made.

It is now 7 years after the announcement of the Vax. We have not recovered from
the event; we do not have a satisfactory Lisp in wide supply; people are
running inferior Lisp environments, they are hanging onto their PDP-10s,
or they have been spending a lot of money on Lisp machines. Since the
personal Lisp workstations have only recently (1 year ago) become available,
6 years without any decent alternative have been suffered.

The idea behind this proposal is that we do not want this to ever happen
again. We want to have a Lisp that is commonly available and uniform enough
over many architectures that the entire AI community can rely on smooth
advancements and shared code. We want the underlying implementation to
be portable and adaptable enough that no forseeable turns of architecture
will create more than a 6-month gap in the availability of a good Lisp system.

Our proposal is to develop a Lisp-in-Lisp system, based on Common Lisp,
with a portable, high performance compiler. A Lisp-in-Lisp system is one
in which almost all of the system is written in Lisp and compiled by
a compiler. To achieve this, the compiler must be able to compile constructs
that manipulate objects normally untouchable by Lisp code. Moreover, the
compiler must be of sufficiently high quality that the performance of the runtime
system is tolerable. 

We believe that with some additional research and a lot of development
we can achieve these goals at this time.

\vskip .25truein
\ctrline{\bf Advantages}

There are a variety of approaches for implementing Lisp on a computer.
These approaches vary both with the architectural support for Lisp by the
target computer and with the philosophy of the implementors.  All of these
approaches, so far, require a compiler; we claim that the most portable
approach relies most heavily on its compiler---since one wants to compile
as much of the runtime system as possible, the coverage of the compiler
and the efficiency of the code it produces are critical.  Thus, the
performance of a portable Lisp depends on the performance of its compiler.

There are two major advantages to Lisp-in-Lisp: the first concerns the
ease of writing correct Lisp code for the system; the second
concerns portability.

With Lisp-in-Lisp, difficult pieces of code can easily be written
correctly.  Typically the most difficult code to write and debug (or prove
correct) is the garbage collector and storage-allocation routines. The
garbage collector, since it operates on data not available to normal Lisp
code, has traditionally been written in assembly language.  A Lisp-in-Lisp
system defines a set of sub-primitives that operate on pointers
directly, and the compiler open-codes them.

Implementing sub-primitives as compiler code generators has three
advantages. First, the template of code that is correctly supplied will be
correctly applied in more situations than were anticipated by the writer
of the code generator. The code-generator writer produces a template or an
abstraction of the code sequence needed to perform the action; the
compiler, and the register allocator in particular, can then supply the
addressing modes and data transfers needed to correctly apply the abstract
sequence of actions in any situation.

Second, routines written in a high-level language can be proven and
debugged more easily. Relatively large-scale modifications can be made
without worry about early commitment to storage layout or register
assignments.

Third, code can be tested within an existing Lisp environment using its
programming tools and with the knowledge that it is a correct language and
environment.  Thus errors in the implementation design and code generators
can be isolated from errors in the Lisp code, the latter being eliminated
while testing in the existing Lisp system.

In addition to the architectural support and philosophical outlook spectra
mentioned above, there is a third spectrum---portability.
Along this spectrum we claim that the microcode-supported Lisp systems and
the large runtime-supported Lisp systems occupy one end (the least portable
end) and Lisp-in-Lisp systems occupy the other end (the most portable end).

Microcoded Lisp implementations assume that a machine exists that directly
implements Lisp instructions, such as CAR, CDR, CONS, etc.  This machine
is referred to as the {\sl abstract machine}, since no hardware actually
implements it.  Since stack-machines are quite convenient for Lisp
implementation, often the abstract machine chosen is a stack machine. The
task of the microcode is to then implement that machine. The hardware that
is thus microcoded is said to {\sl emulate the abstract machine}.  The
task of writing microcode is comparable to the task of writing a large
runtime system; when portability is needed, a compiler that assumes code
generators for sub-primitives can be more easily portable than one that
produces code for a stack machine.  For a compiler that produces code for
a stack machine, each instruction emitted is an {\sl abstract-machine}
instruction, and each abstract-machine instruction emitted requires
microcode or macrocode support, or else each such instruction must be
expanded into native machine code.

Three major Lisp implementations that use this methodology are PSL
\ref:Griss.1982., \hbox{InterLisp-D} \ref:Burton.1980. \ref:Moore.1976.,
and ZetaLisp \ref:Weinreb.1983.. PSL is targetted at stock-hardware
computers (VAX 11/780, DEC 2060, CRAY-1, MC68000-based machines, and others),
InterLisp-D is targetted at both stock-hardware and microcoded machines
(Vax 11/780, Dolphin, Dorado, Dandelion, Jericho), and ZetaLisp is
targetted at the LM-2 and the 3600.  PSL expands abstract-machine
instructions using CMACROS to hardware instructions; ZetaLisp assumes
microcode support for their abstract machines; and \hbox{InterLisp-D}
expands abstract-machine instructions to hardware instructions in the case
of the Vax and assumes microcode support in the case of the D-machines.
(Note that along with \hbox{InterLisp-10}, the InterLisp family forms a
`common' Lisp, being available on the PDP-10, the VAX, and a variety of
personal machines.)

If each abstract-machine instruction is expanded as part of the last,
code-producing pass of the compiler, then register-allocation decisions
depend only on earlier register-allocation decisions.  This renders high
quality register-allocation and, hence, high performance difficult to
achieve.

In a Lisp-in-Lisp environment the large runtime system is written in
Lisp and only the components needed to piece that system together (the
sub-primitives) are hand-coded as simple code generators. Therefore the
portability of a Lisp-in-Lisp system is the highest at the end of
this spectrum.

Richard Gabriel has been working on a Common Lisp \ref:Steele.1982. for
the \S-1 Mark IIA super-computer being developed at LLNL, producing an
implementation that has high performance, exploits the complex
architecture of the \S-1, and which is almost entirely written in Lisp
\ref:Brooks.1982b..  This Lisp implementation is possibly the most
portable for its performance since is has a highly optimizing compiler.

Portable Standard Lisp (PSL) \ref:Griss.1982. is the closest to the \S-1 Lisp in
terms of being a true Lisp-in-Lisp. The \S-1 implementation has a more
advanced compiler and is, therefore, of higher performance.
\hbox{InterLISP-D} \ref:Burton.1980. \ref:Moore.1976. is a Lisp-in-Lisp
system where the sub-primitives required are written in microcode.
\hbox{InterLisp-Vax} uses the \hbox{InterLisp-D} Lisp-in-Lisp code, but it
demonstrates compiler/architecture mismatch \ref:Masinter.1981.
\ref:Gabriel.1982.  \ref:Gabriel.1983..

T \ref:Rees.1982. uses an early version of the \S-1 compiler, adapted to the Vax.

\vskip .25truein
\ctrline{\bf Common Lisp}

This section and the next two are an overview of the 
organization of Common Lisp.

Common Lisp is the combined effort of eight different Lisp implementation
groups aimed at producing a common dialect of Lisp while allowing each
group to exploit its own hardware.  These groups are: Spice Lisp at CMU,
DEC Common Lisp on Vax at CMU, DEC Common Lisp on DEC-20 at Rutgers, S-1
Lisp at LLNL, Symbolics Common Lisp, LMI Common Lisp, Portable Standard
Lisp at Utah, and Vax NIL.  Common Lisp is a set of documents, a language
design, and a common body of code.

The main goal of Common Lisp is to unify the experiences of the
Lisp implementations that are descended, either historically or
philosophically, from MacLisp. MacLisp is a dialect of Lisp that
emphasizes ease of system-building and efficient execution of numeric
code.  

Other goals of Common Lisp are to provide a workbench programming
language for artificial intelligence, symbolic algebra, robotics,
and education for the next decade. With such a commonly available
and commonly used Lisp it would be possible for researchers to
exchange programs with a minimum of effort, even though the host
computers could be very different. Such a Lisp would be powerful enough
to write a sophisticated operating system sufficient to support its
own use and would, thereby, prove to be a useful systems research tool
as well as a tool for creating Lisp machine environments.

With a powerful Lisp widely available, research centers might not have
to consider the language features of the Lisp(s) available on various
computers as part of the decision regarding what hardware to purchase.
In this way a more intelligent and effective choice could be made.

Common Lisp should support an easily-understood, portable programming style.
By making a large number of packages written in Lisp available it is hoped 
that not only would the amount of work needed to get a system running be
low, but the overall programming style and methodology would be improved
through exposure to the code written by expert programmers.

\vskip .25truein
\ctrline{\bf History of Common Lisp}

After the usefulness of the PDP-10 as a Lisp engine declined because its
address space was limited to 18 bits, several implementation groups
started to implement Lisps for computers with larger address spaces, and
these implementors tried to improve and extend MacLisp, both to take
advantage of lessons learned from MacLisp and the various languages built
on top of it (Scheme, for example) and to also exploit the architectures
the implementors were using.

It soon became clear to several of the implementors (Richard Gabriel of
Stanford and Lawrence Livermore National Laboratory, Guy L. Steele Jr. of
Carnegie-Mellon University, Jon L. White then of the Massachusetts
Institute of Technology, and Scott Fahlman of Carnegie-Mellon University)
that the situation of four different Lisps---Vax NIL, SPICE Lisp, Lisp
Machine Lisp, and Franz Lisp---all descended from MacLisp, all used by
ARPA-sponsored institutions, and each different from the others in subtle,
yet important, ways, was intolerable to the research community. Several
key meetings among the implementors resulted in an initial commitment to
unify the approaches in the form of a large, common subset, which was to
be called `Common Lisp.' Of the four major Lisp implementations, only
Franz Lisp did not appear interested in joining the Common Lisp group, and
for financial rather than philosophical reasons.

Since this informal group got together, the language, Common Lisp,
has been largely designed and a manual written that describes the
language at user-level.  The original informal group has expanded into a
larger, formal committee which is collaborating on the language design and
documentation in a loose fashion. This group, called the `Common Lisp
Group', maintains a mailing list and an archive of working messages at
SAIL (Stanford Artificial Intelligence Laboratory).
Many decisions have been made about the political organization of Common
Lisp and about what the manual does and does not require of an
implementation.

To be most useful, Common Lisp must support a large body of packages and
routines, so that a tradition of code, so to speak, is maintained. For
example, pattern matchers, object-oriented programming packages, and
indexing routines should be available so that projects requiring these
tools can use existing, well-tested code. In addition, these packages
ought to be of certified quality of functionality and documentation.

If Common Lisp is to be widely used it must be available on hardware not
currently supporting Common Lisp dialects. Since Common Lisp is a large
language, producing a working Common Lisp simply from the manual would
require several man-years of effort. One of the next tasks to be
undertaken is to define Common Lisp in terms of a {\sl virtual machine}
description.

Such a description is a formal definition of a number of primitives that
must be defined on the hardware in question. Then the remainder of Common
Lisp is defined as a body of Common Lisp code written with the assumption
that these primitives exist. Once these primitives are defined on a piece
of hardware, a Common Lisp interpreter is gained by `loading' the body of
Common Lisp code.

\vskip .25truein
\ctrline{\bf Documentation for Common Lisp}

Currently Common Lisp is nothing more than an organization for
documentation along with some of that documentation. To be complete
as envisioned by the Common Lisp Group, the rest of the documentation
must be brought into existence.

The Common Lisp documentation is divided into four parts, known as the
{\sl white pages}, the {\sl yellow pages}, the {\sl red pages}, 
and the {\sl blue pages}.

The {\sl white pages} is a language specification rather than an implementation
specification.  It defines a set of standard language concepts and
constructs that may be used for communication of data structures and
algorithms in the Common Lisp dialect.  This is sometimes referred to as
the ``core Common Lisp language,'' because it contains conceptually
necessary or important features.  It is not necessarily implementationally
minimal.  While some features could be defined in terms of others by
writing Lisp code (and indeed may be implemented that way), it was felt
that these features should be conceptually primitive so that there might
be agreement among all users as to their usage.  (For example, bignums and
rational numbers could be implemented as Lisp code given operations on
fixnums.  However, it is important to the conceptual integrity of the
language that they be regarded by the user as primitive, and they are
useful enough to warrant a standard definition.)

The {\sl yellow pages} is a program library document, containing documentation
for assorted and relatively independent packages of code.  While the white
pages are to be relatively stable, the yellow pages are extensible; new
programs of sufficient usefulness and quality will routinely be added from
time to time.  The primary advantage of the division into white and yellow
pages is this relative stability; a package written solely in the
white-pages language should not break if changes are made to the
yellow-pages library.

The {\sl red pages} is implementation-dependent documentation; there will
be one set for each implementation.  Here are specified such
implementation-dependent parameters as word size, maximum array size,
sizes of floating-point exponents and fractions, and so on, as well as
implementation-dependent functions such as input/output primitives.

The {\sl blue pages} constitutes an implementation guide in the spirit of the
Interlisp virtual machine specification.  It specifies a subset of the
white pages that an implementor must construct, and indicates a quantity
of Lisp code written in that subset that implements the remainder of the
white pages.  In principle there could be more than one set of blue pages,
each with a companion file of Lisp code.  (For example, one might assume
{\sc IF} to be primitive and define {\sc COND} as a macro in terms of IF, while
another might do it the other way around.)

\vskip .25truein
\ctrline{\bf The Proposal}

This proposal is a major supplement to the work already being done under
contract from the Defense Advanced Research Projects Agency.

Stanford University currently has in place a contract to perform
the following three tasks; these tasks are largely document-writing
tasks with some programming and quality control:

The first task is to complete the white
pages: though Guy Steele will be able to work several hours a week on that
task while at Tartan Labs, it may prove impractical for him to spend all
the time needed for the job. We will help him finish the writing and
editing, arrange and direct the Common Lisp Group meetings, and perform
the administrative work necessary to complete the language specification
and documentation.

The second task is to produce the first version of the yellow pages. This
task consists of gathering proposed packages, validating the
documentation, insuring the portability, and doing some testing of the
code before it is included in the yellow pages. All code will be uniformly
housed at Stanford with access to all ARPA contractors.  This document and
library is to be completed by the end of December 1984.

Finally, and most importantly, the third task is to produce the first
version of the blue pages. This requires producing a detailed
specification of the subset of the white pages that must be implemented by
an implementation group to support Common Lisp, expanding on the white
pages description where necessary. We will also write, test, and document
an implementation of Common Lisp in that subset and make that code
available to anyone wanting to implement a Common Lisp. Thus, for any
group to implement a Common Lisp, all that will need to be done is to
write the specified language subset in whatever other language their
hardware supports and to then take a copy of the Lisp code we will have
produced which will complete the implementation of the white pages
language.  This document and code is to be completed by the end of
December 1985.

We propose to supplement these tasks with four others:

\numitem{1.}the development of
a portable, high-performance Common Lisp compiler;

\numitem{2.}the development of a subset Common Lisp dialect along with
a `graceful expansion' methodology that allows Common Lisp to run
effectively on the current herd of microprocessor-based computers while
retaining the full power of Common Lisp.

\numitem{3.}the development of a program that will examine a body of
Common Lisp code and translate as much of it as possible into the
subset mentioned above. Where such translation is impossible, this program
will produce a list of packages (files) that must be loaded to execute
that body of code directly.

\numitem{4.}the development of a semi-automatic type-deduction system that
will help users of generic Common Lisp declare the types of their code.
This system will discover the types of as many variables as possible automatically
and will inquire about the smallest set of variables necessary to determine
types of the remainder.

\vskip .25truein
\ctrline{\bf Small Computers}

Currently there is a trend towards small computers, the motivation being
that the performance of microprocessor-based computers is rapidly increasing,
and it is desirable for each researcher to have his own computer in his office.

We, the implementors of Lisp systems, must respond to these developments.
It is clear that Common Lisp must be available on these machines.

However, despite the good overall performance of these machines (we have
in mind the MC68000-based computers), their performance on a large Lisp
system---where the most common operations would be among the lowest performance
on the hardware---is expected to be poor. 

We propose to delineate a subset of Common Lisp that will run well on
small computers, such as the MC68000-based computers. If the user writes
code outside of this subset but within Common Lisp, the code will still work,
though it may run slowly. This way people can write code that will be portable
to the entire Common Lisp community, although portability in the direction
of small computers may be less pleasant.

To accomodate these low-end users, we will publish a style manual for Yellow
pages code. This manual will not only outline the style requirements for code appearing
in the Yellow pages, but it will also specify a level of type declarations.

Since Common Lisp supports generic operations, Lisp code for implementations on stock
hardware must either be heavily declared as to the data types of its objects or
type-specific operations must be faithfully used. Yellow pages code must be
as extensively declared and type-specific as Common Lisp allows.

Furthermore, Yellow pages packages must lie as fully within the small-implementation
subset as possible, so that the performance of these packages will be as high as
possible on all implementations.

\vskip .25truein
\ctrline{\bf Compiler}

Of course, the blue pages is not complete without a portable compiler.
Such a compiler could be of the form of a machine-independent portion and
a machine-dependent portion. The machine-independent portion can perform
source-to-source transformations, flow analysis, data-structure analysis,
tail-recursion analysis, and environment analysis. The machine-dependent
portion can perform target annotation, register allocation, and code
generation. The S-1 compiler for Common Lisp is largely structured this
way. Many of the machine-dependent parts are table-driven. This compiler
could be adapted for use as a portable Common Lisp compiler.

The generation of a complete Common Lisp can be made relatively simple using
a compiler which compiles {\sl sub-primitives} such as those necessary for
doing storage allocation and performing garbage collection. The S-1 Common Lisp
system is built this way, and only about 400 lines of assembly language code
is required to build the Lisp system.

We propose to write a portable Common Lisp compiler, based on the
technology developed for the S-1 compiler \ref:Brooks.1982a.. We will
develop an architectural description language that will be used in
conjunction with the register-allocator, the data-moving code, and the
code generators to produce high-quality compilers. In short, we will
produce a Common Lisp compiler-compiler, borrowing techniques from the CMU
PQCC project\ref:Leverett.1979..

The target machines that we will use will be a MC68000-based microcomputer,
such as the SUN or Apollo, and a RISC architecture, such as the DEC Titan
being built by Forest Baskett.

Richard Gabriel, Rodney Brooks, and Paul Wieneke of Stanford University
will work on the compiler-compiler.  In addition, we will need to hire one
research associate and two students.  Since a number of other projects
(within universities and private companies) are interested in a Portable
Common Lisp, we will actively seek collaborations; in particular,
Symbolics Inc., Digital Equipment Corporation, and Jonathon Rees at Yale
(the T project) have expressed interest in collaboration. If such
collaborations become feasible, we will be able to reduce the personnel
requirements for Stanford.

% References
\vskip .25truein
\ctrline{\bf References}

\makeref:Brooks.1982a.{Brooks, R. A., Gabriel, R. P., Steele, G. L.
\article{An Optimizing Compiler For Lexically-Scoped Lisp},
Proceedings of the 1982 ACM Compiler Construction Conference,
June, 1982.}

\makeref:Brooks.1982b.{Brooks, R. A., Gabriel, R. P., Steele, G. L.
\article{\hbox{\S-1} Common Lisp Implementation},
Proceedings of the 1982 ACM Symposium on Lisp and Functional
Programming, August 1982.}

\makeref:Burton.1980.{Burton, R. R., Masinter, L. M., Bobrow, D. G.,
Haugeland, W. S., Kaplan, R. M., Sheil, B. A., Bell, A.
\article{Overview and Status of \hbox{InterLISP-D} (Dorado and Dolphin)},
Proceedings of the 1980 ACM Symposium on Lisp and Functional
Programming, August 1980.}

\makeref:Gabriel.1982.{Gabriel, R. P., Masinter, L. M.
\article{Performance of Lisp Systems},
Proceedings of the 1982 ACM Symposium on Lisp and Functional
Programming, August 1982.}

\makeref:Gabriel.1983.{Gabriel, R. P., Griss, M. L.
\article{Lisp on Vax: A Case Study},
in preparation.}

\makeref:Griss.1982.{Griss, M. L., Benson, E. B., Maguire, G. Q.
\article{PSL: A Portable Lisp System},
Proceedings of the 1982 ACM Symposium on Lisp and Functional
Programming, August 1982.}

\makeref:Leverett.1979.{
Leverett, Bruce W.; Cattell, Roderic G. G.; Hobbs, Steven O.;
Newcomer, Joseph M.; Reiner, Andrew H.; Schatz, Bruce R.; and
Wulf, William A., \article{
An Overview of the Production Quality Compiler-Compiler Project},
Technical Report CMU-CSD-79-105, Carnegie-Mellon University,
Computer Science Department, February, 1979.}

\makeref:Masinter.1981.{Masinter, L. \book{\hbox{Interlisp-VAX:} A Report},
Department of Computer Science, Stanford University, STAN-CS-81-879,
August 1981.}

\makeref:Moon.1974.{Moon, David.
\book{MacLisp Reference Manual, Revision 0},
      M.I.T. Project MAC, Cambridge, Massachusetts, April 1974.}

\makeref:Moore.1976.{Moore II, J. S. \article{The InterLISP Virtual Machine
Definition}, Tech. Rept. CSL 76-5, Xerox Palo Alto Research Center, Palo Alto,
California, Sept. 1976}

\makeref:Rees.1982.{Rees, J. A., Adams, N. I.
\article{T: A Dialect of Lisp or, LAMBDA: the Ultimate Software Tool},
Proceedings of the 1982 ACM Symposium on Lisp and Functional
Programming, August 1982.}

\makeref:Steele.1982.{Steele, Guy Lewis Jr. et al.
\article{An Overview of Common Lisp},
Proceedings of the 1982 ACM Symposium on Lisp and Functional
Programming, August 1982.}

\makeref:Teitelman.1978.{Teitelman, Warren, et al. \book{Interlisp Reference
Manual}, Xerox Palo Alto Research Center, Palo Alto, California, 1978.}

\makeref:Weinreb.1983.{Weinreb, Daniel, and Moon, David.
\book{LISP Machine Manual}, Fourth Edition.
      Massachusetts Institute of Technology Artificial Intelligence
         Laboratory, Cambridge, Massachusetts, July 1981.}

\makeref:Wulf.1975.{Wulf, William; Johnsson, Richard K., Weinstock, Charles B.,
Hobbs, Steven O., and Geschke, Charles M.
\book{The Design of an Optimizing Compiler},
Programming Language Series, Volume 2, American Elsevier, New York, 1975.}

\vfill\eject
% Budget    
\vskip .25truein
\ctrline{\bf BUDGET}
\ctrline{Proposal to the Defense Advanced Research Projects Agency}
\ctrline{John McCarthy, Principal Investigator}
\ctrline{October 1, 1983 - September 30, 1986}

$$\vcenter{\halign to size{#\hfill\tabskip 0pt plus 100pt
⊗\hfill #⊗\hfill #⊗\hfill #⊗\hfill #\tabskip 0pt\cr
⊗10/1/83 -⊗10/1/84 -⊗10/1/85 -\cr
Item⊗9/30/84⊗9/30/85⊗9/30/86⊗Total\cr
\noalign{\vskip 2pt\hrule\vskip 2pt}
SALARIES\cr
Faculty\cr
\ \ \ Prof. John McCarthy, no cost to project\cr
\ \ \ Acting Asst. Prof. Rodney Brooks, 10\%⊗4,000⊗4,320⊗4,665⊗12,985\cr
Research Associate (1)⊗30,000⊗32,400⊗34,992⊗97,392\cr
Student Research Assts. (2)⊗23,550⊗25,434⊗27,469⊗76,453\cr
\ \ \ 50\%\ 9 mo., 100\%\ summer\cr
Sectl. Support, 15\% ⊗3,011⊗3,252⊗3,512⊗9,775\cr
\noalign{\vskip 2pt\hrule\vskip 2pt}
\ \ \ Subtotal, Salaries⊗60,561⊗65,406⊗70,638⊗196,605\cr
\cr
STAFF BENEFITS⊗13,833⊗15,201⊗16,770⊗45,804\cr    
\ \ \ 10/1/83 - 9/30/84,\ \ \ 22.8\%\cr
\ \ \ 10/1/84 - 9/30/85,\ \ \ 23.2\%\cr
\ \ \ 10/1/85 - 9/30/86,\ \ \ 23.7\%\cr
\cr
TRAVEL, Domestic⊗7,000⊗7,560⊗8,165⊗22,725\cr
\ \ \ 5-6 East Coast trips per year for research\cr
\ \ \ collaboration at MIT and CMU\cr
\cr
EXPENDABLES⊗1,000⊗1,080⊗1,167⊗3,247\cr
PUBLICATIONS⊗1,000⊗1,080⊗1,167⊗3,247\cr
CSD COMPUTER FACILITIES⊗19,000⊗20,520⊗22,162⊗61,682\cr
\noalign{\vskip 2pt\hrule\vskip 2pt}
TOTAL DIRECT COSTS⊗102,394⊗110,847⊗120,069⊗333,310\cr
INDIRECT COSTS\ \ \ 69\%⊗70,652⊗76,485⊗82,848⊗229,985\cr
\noalign{\vskip 2pt\hrule\vskip 2pt}
TOTAL COSTS⊗$\$$173,046⊗$\$$187,332⊗$\$$202,917⊗$\$$563,295\cr}}$$

\vfill\end